It is to be noted that the discussions contained in the “Background” section and in the present section relating to prior art arrangements relate to devices, processes or published documents. Such should not be interpreted as a representation by the present inventor(s) or patent applicant that such devices, processes or published documents in any way form part of the common general knowledge in the art.
Corporations typically build Virtual Private Networks (VPNs) by interconnecting Local Area Networks (LANs) in geographically distributed sites via physical or virtual leased lines. The bandwidth of these long-distance leased lines is, however, typically orders of magnitude lower than the bandwidths available in the LANs. Consequently, gateways interconnecting these high-speed LANs to the much slower long-distance leased lines can be the source of congestion, causing large packet queues, delay, jitter and packet loss.
In IP networks, hosts in one geographic site transmit IP packets to another (distant) site over the leased lines through the gateways. These IP packets may carry voice, video and other data. If there is congestion in a gateway, the packets transiting the gateway can be delayed or even lost due to buffer overflow in the gateway. Delay, variability of delay (commonly referred to as jitter) and packet loss can drastically reduce the performance of multimedia applications which are running between two host machines located in different sites.
To control congestion in IP networks, a transport layer protocol, called the Transmission Control Protocol (TCP), is used to pace the flow of data from source to destination. However, TCP operates on a time scale of Round-Trip Times (RTTs) which can be very large, when compared to the bit period of the traffic being considered, for long distance communications networks. With the emergence of high-speed multimedia applications running across multiple geographically separated sites, congestion at site gateways can build up in a much shorter time scale than the TCP control mechanisms can respond, thereby rendering TCP's congestion control unsatisfactory in many situations.
U.S. patent application Ser. No. 09/944,746, now U.S. Pat. No. 6,741,563 describes a method of adjusting the TCP window size at the gateway in order to control the data flow of a given TCP connection. Since TCP window size information is encapsulated in the Internet Protocol (IP) payload, this approach requires the gateway to have access to the IP payload. It is difficult to provide access to the IP payload at intermediate nodes such as gateways, and it may even not be possible, for example in secure communication environments where IP payloads may be encrypted using the IP Security Protocol IPSEC. A similar method, which also adjusts the TCP window size at the gateway is described in U.S. patent application Ser. No. 09/770,215, now U.S. Pat. No. 6,925,060. The approach described here is not suitable for environments where the IP payloads are encrypted, since it relies on adjustment of the TCP window size at the gateway.
A third method, proposed in “HGRCP: A rate-based flow control mechanism for Intranets interconnected by ATM networks” by Hassan et al., Computer Networks, Volume 31, No. 22, pages 2361-2379, December 1999 uses a rate signalling-protocol between the gateway and the hosts to control an aggregate rate of each host. This method does not, however, prevent individual applications in a given host competing in an unfair manner with each other for bandwidth resources between sites.